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I. 


DEFINING  THE  ARCHITECTURE  CONTEXT  AND  ISSUES 


A.  PROBLEM  CHARACTERIZATION 

Today’s  Joint  battle  space  can  be  characterized  as  a  community  of  systems 

(sensors,  platforms)  and  actors  (Joint  &  Coalition)  that  are  equipped  with 
primarily  stove  piped  systems  that  at  best  function  merely  to  enable  connectivity 
and  interoperability.  By  design,  these  systems  disseminate  &  exchange 
information  &  knowledge  among  select  nodes  and  stakeholders.  In  order  for  the 
Joint  force  to  truly  become  Network  Centric,  all  future  sensors,  platforms,  actors 
(decision  makers  and  shooters)  must  be  effectively  networked  in  order  to  achieve 
a  shared  awareness,  increased  speed  of  command,  higher  tempo  of  operations, 
greater  lethality,  increased  survivability,  and  a  degree  of  self  synchronization.1 

Presently,  the  JFACC’s  Theater  Battle  Management  Core  System  (TBMCS) 
incorporates  much  of  Network  Centric  Warfare’s  (NCW)  intent  in  its  design. 
However,  in  practice  the  preponderance  of  this  information  lies  solely  within 
select  headquarters  work  stations  and  neither  reaches  nor  exchanges 
information  with  all  battle  space  end  users  in  real  time.2  For  example,  no 
USMC  helicopters  are  equipped  to  receive  or  transmit  any  type  of  data  link  or 

1  Network  Centric  Warfare:  Developing  &  Leveraging  Information  Superiority,  David  Alberts,  John  Garstka,  Frederick 
Stein.  CCRP  Publications  series,  February  2000.  p.  2. 

^  Theater  Battle  Management  Core  Systems  (TBMCS)  is  the  Combat  Air  Force  (CAF)  information  and  decision  system 
supporting  combined  and  joint  air  operations  for  the  Joint  Forces  Commander  (JFC).  It  integrates  the  Contingency 
Theater  Automated  Planning  System  (CTAPS  -  the  force  level  planning  system),  Wing  Command  and  Control  System 
(WCCS  -  the  wing  level  execution  system),  and  Combat  Intelligence  System  (CIS  -  the  intelligence  system)  under  a 
common  core  of  services.  TBMCS  functionality  includes  intelligence  processing;  air  campaign  planning,  execution  and 
monitoring;  aircraft  scheduling;  unit-level  maintenance  operations;  unit-  and  force-level  logistics  planning;  and  weather 
monitoring  and  analysis.  At  the  force  level,  TBMCS  supports  the  JFC  through  the  Air  Operations  Center  (AOC)  and  Air 
Support  Operations  Center  (ASOC).  At  the  unit  level,  TBMCS  supports  the  Wing  Commander  through  the  Wing 
Operations  Center  (WOC),  Maintenance  Operations  Center  (MOC),  and  Squadron  Operations  Center  (SOC).  DISA: 
Global  Command  &  Control  System  TBMCS.  http://iitc.fhu.disa.mil/gccsiop/interfaces/tbmcs.htm 
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common  operational  picture  (COP).  In  fact,  none  are  equipped  with  a  digital  map 
display.  GPS  data  is  displayed  in  text  format  on  the  console’s  programming 
screen  or  as  a  simple  heading  pointer  overlay  on  the  cockpit’s  Forward  Looking 
Infrared  (FLIR)  display.  Combat  mission  planning  consists  of  manually  entering 
route  &  threat  information  into  the  Navy  Portable  Flight  Planning  Software  (N- 
PFPS).  N-PFPS  can  be  used  with  all  DOD  type/model/series  aircraft.  This 
application  stores  &  displays  geodetic  charts  and  imagery  of  various  scales, 
known  route  hazards,  navigational  aids,  airports,  and  accepts  wind  data  to 
calculate  air  speeds,  flight  headings,  &  fuel  flows.  In  the  case  of  the  CH-53E 
helicopter,  the  mission  data  is  saved  to  a  Mission  Data  Loader  (MDL  or  “Brick”) 
and  loaded  into  the  aircraft.  The  brick  simply  stores  the  planned  route  waypoints 
for  loading  into  the  aircraft’s  on  board  Global  Positioning  System  (GPS).  The 
pilot  selects  the  route  to  fly  and  the  GPS  provides  updated  heading,  course,  & 
timing  information  to  navigate  the  planned  route.  There  is  no  dynamic  download 
or  exchange  of  information  in  this  process.  Any  significant  changes  that  affect 
the  mission  are  relayed  via  voice  communications  en  route  or  discovered  “on  the 
fly”  as  the  plan  unfolds.  This  is  the  current  state  of  Marine  heavy,  medium,  and 
light  attack  helicopters. 

B.  GOAL 

This  paper  proposes  an  Information  Awareness  Module  ( l-AM ) 
architecture  that  addresses  the  innate  need  for  shared  battle  space  awareness 
among  aviation  entities  in  real  to  near  real  time.  Though  this  architecture  will  be 
described  from  a  helicopter  vantage,  it  is  not  limited  to  this  entity  class.  Rather, 
the  intent  has  been  to  adopt  an  architectural  framework  that  supports  a  product 
line  approach  capable  of  addressing  this  basic  battle  space  need  of  all  entities 
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(Air,  Ground,  Sea).  This  shared  awareness  is  facilitated  by  the  tailored  exchange 
of  information  that  by  nature  should  be  inherently  valuable,  relevant,  and  timely 
to  any  user  or  platform  requiring  it. 
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II.  STRATEGIC  CONCEPT 


A.  THE  VISION  BEHIND  THE  l-AM  ARCHITECTURE 

The  vision  behind  this  proposed  architecture  can  be  best  understood  through 

the  following  operational  vignette: 

The  Joint  Force  Air  Component  Commander’s  (JFACC)  Air  Tasking  Order  (ATO)  for  the 
following  day’s  air  operations  was  released  at  1800z.  On  board  the  amphibious  assault  ship 
Tarawa,  pilots  of  Marine  Heavy  Helicopter  Squadron  (HMH)  465  (Reinforced)  continued  their 
mission  planning  for  the  following  day’s  assault.  HMH-465  was  a  composite  squadron  and  was 
designated  as  the  Aviation  Combat  Element  (ACE)  for  the  15th  Marine  Expeditionary  Unit  (MEU). 
The  squadron  was  comprised  of  a  mix  of  CH-53X,  AH-1Y,  UH-1Z,  MV-22,  and  Joint  Strike  Fighter 
(JSF)  aircraft.  Utilizing  Information  Awareness  Module  (l-AM)  mission  planning  client  terminals  in 
the  Ready  Room,  pilots  were  able  to  access  a  mission  planning  application  that  dynamically 
fused  and  interacted  with  the  Joint  Operation  Area  Information  Grid  (JIG).  Upon  entering  the 
ATO  assigned  mission  ID,  their  “slice”  of  the  battle  space  was  filtered  and  made  available  for 
planning.  Routing  options  were  displayed  based  upon  the  constraints  &  framework  of  the  Air 
Tasking  Order  (ATO),  the  Air  Space  Control  Order  (ACO)  &  Special  Instructions  (SPINs).  Threat 
observations,  assessments,  and  expectations  fed  from  the  Enemy  Air/Ground  Order  of  Battle 
information  were  fused  with  the  Commander’s  Intent  (strategic  through  tactical),  the  Friendly 
Air/Ground/Sea  Orders  of  Battle  and  Meteorological  (METOC)  information  that  generated 
optimum  mission  paths  for  aircrew  selection.  The  pilots  then  entered  the  detailed  mission 
specifics  (number  of  aircraft,  specific  take  off/landing  times,  fuel  &  ordnance  loads,  LZs,  targets, 
objectives,  etc.)  and  system  calculated  go-no-go  criteria,  optimum  airspeeds,  ordnance,  fuels 
loads,  divert  options,  and  printable  knee  board  mission  “smart  packs.  ”  The  mission  commander 
approved  the  plan,  and  it  was  simultaneously  uploaded  into  the  JIG  and  down  linked  (or  manually 
disk  loaded)  into  each  of  the  squadron’s  aircraft  in  preparation  for  the  following  day’s  mission. 

The  aircrew  manned  up  their  aircraft  at  0600.  /4s  the  on  board  flight  computers  came  on  line, 
each  aircraft’s  l-AM  logged  into  the  JIG.  Immediately,  updates  from  the  last  24  hours  of  battle 
were  received  and  the  preplanned  mission  was  dynamically  updated  &  transformed  into  a  current 
model  for  execution.  As  the  aircraft  lifted  off  and  proceeded  feet  dry,  on  board  sensors  (GPS, 
Radar  Warning  Receivers),  Navigational  Instruments  (airspeed,  barometric  altimeter,  fuel 
flow/quantity,  etc.),  and  the  IFF  command  &  control  module  (Identification  Friend  or  Foe  C2) 
began  to  publish  the  current  state  of  each  aircraft  as  they  pressed  on  along  their  mission  ingress 
routes.  Intra-flight  and  inter-JIG  communication  was  minimized  by  adhering  to  the  rule  of 
publishing  information  by  exception.  That  is,  there  was  no  requirement  for  mission  status 
updates  as  long  as  the  flight  proceeded  within  the  plan  tolerance  “known”  by  all  need  to  know  JIG 
C2  entities.  Occasional  aircraft  “heartbeats”  published  the  aircraft  state  to  the  JIG  in  order  to 
facilitate  C2  and  avert  fratricide.  These  status  heart  beats  were  programmed  to  occur  on  a 
seemingly  random,  yet  algorithmically  controlled  basis  to  counter  enemy  tracking  &  spoofing. 

As  the  flight  approached  phase  line  red,  the  aircrew  completed  their  penetration  checklists. 
Door  gunners  test  fired  their  weapons,  and  the  aircraft  assumed  a  terrain  flight  (TERF)  profile  at 
50  feet  to  avoid  enemy  radar  detection.  Satellite  ELINT  sensors  orbiting  high  over  the  joint 
operating  area  detected  new  enemy  early  warning  &  target  tracking  radars  associated  with  a 
surface  to  air  missile  launcher  in  close  proximity  to  the  route’s  Initial  Point  (IP).  Once  detected, 
the  information  was  published  to  the  JIG  where  it  was  then  routed  to  all  entities  that  were  either 
determined  to  be  in  critical  need  or  were  valid  subscribers  of  this  particular  subset  of  information. 
Immediately,  the  cockpit  information  display  alerted  the  pilots  of  critical  new  information  that 
directly  impacted  the  planned  mission.  The  aircrew’s  attention  was  immediately  drawn  to  the 
digital  map  display  where  the  new  threat  was  accurately  plotted  complete  with  threat  rings.  The 
copilot  immediately  selected  the  hazard  avoidance  overlay  button  and  three  optimum  routes  to 
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the  LZ  were  displayed  over  the  existing  profile.  Since  L-Hour  was  firm,  the  Air  Mission 
Commander  selected  the  option  that  ensured  the  mission  would  meet  its  time  on  target  (TOT)  in 
addition  to  maximizing  the  fuel  available  for  the  AH-1Y  escorts.  Instantaneously,  the  JIG  &  all 
aircraft  in  the  flight  were  updated  with  the  new  plan  information.  As  the  flight  maneuvered  along 
their  new  route,  the  Joint  Strike  Fighters  escorts  quickly  neutralized  the  pop  up  threat.  The  rest  of 
the  mission  proved  to  be  uneventful.... 

This  futuristic  network  centric  operational  vision  was  the  primary  impetus  that 
inspired  the  architecture  presented  in  this  paper.  It  was  further  refined  by 
adopting  the  VIRT  -  Valued  Information  at  the  Right  Time  -  construct  presented  in 
class.  One  of  the  key  tenants  inherent  to  the  VIRT  construct,  and  the  l-AM 
architecture,  is  the  concept  of  efficient  thought.3  There  are  eight  steps  that 
comprise  the  efficient  thinking  decision  loop.  “Each  [step]  is  supported  by  a 
world  model  that  represents  our  best  understanding  of  how  things  work.”4  In  the 
l-AM  architecture,  the  world  model  is  equivalent  to  the  Joint  Operation  Area 
model  and  consists  of  information  across  several  domains  such  as  Commander’s 
Intent  (Strategic,  Operational,  Tactical),  Rules  of  Engagement  (ROE),  Air  Space 
Control  Order  (ACO),  Air  Tasking  Order  (ATO),  Special  Instructions  (SPINS), 
Enemy  Order  of  Battle,  Friendly  Order  of  Battle,  Operation  Orders  and  Plans, 
Logistics  models,  Joint  Prioritized  Target  List  (JPTL),  Master  Air  Attack  Plan, 
threats,  C  ,  METOC  data,  imagery,  Bomb  Damage  Assessments  (BDA),  and 
mission  route  planning  to  name  a  few.  More  than  just  a  reservoir  of  information, 
the  world  model  spans  the  battle  space  time  continuum  of  past,  present,  &  future. 
It  maintains  historical  data  and  outcomes  of  past  plans,  tactics,  &  procedures.  It 
models  and  predicts.  In  the  current  state,  it  fuses  sensor  &  planning  information 

3  Hyper-Beings:  How  Intelligent  Organizations  Attain  Supremacy  through  Information 
Superiority,  Part  I,  pre-publication  DRAFT.  Dr.  Rick  Hayes-Roth,  Nov  2003,  p.  46. 

4  Hyper  Beings  p.  46 
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and  infers  a  forecast  state  from  previous  successes,  &  failures.  Additionally,  it 
produces  candidate  plans,  or  potential  courses  of  action  (COAs)  in  real  time  to 
counter  unexpected  outcomes  or  invalid  planning  assumptions.  Finally,  the 
model  itself  can  be  changed  to  more  closely  align  the  virtual  world  with  the  battle 
space  reality. 

The  eight  steps  in  the  efficient  thought  decision  loop  are  manifested  in  the  I- 
Am  architecture  as  follows:  (1)  Observe:  The  l-AM  observes  the  environment  by 
monitoring  data  received  by  an  array  of  indigenous  onboard  sensors  (Global 
Positioning  Satellites  (GPS),  Inertial  Navigation  Systems  (INS),  Radar  Warning 
gear  (RAW)  and  various  avionics  components  (airspeed,  barometric  altimeter, 
engine  &  flight  instruments)  as  well  as  decoupled,  distributed  external  sensors 
data  from  satellites,  aircraft,  and  various  ground  based  systems.  This 
information  is  then  used  to  update  the  JOA  world  model.  (2)  Assessment:  The 
observed  information  is  compared  against  the  forecast  plan  model.  (3)  Changes: 
The  l-AM  determines  the  degree  of  changes  to  make  to  the  model.  (4)  Generate 
Candidate  Plans:  Candidate  COAs  are  generated  and  submitted  to  the  pilot  for 
acceptance  (i.e.  propose  alternative  routing  to  circumvent  pop-up  threat)  (5) 
Project  Likely  Outcomes:  The  ramifications  for  selecting  a  COA  are  modeled  and 
analyzed.  For  example,  a  candidate  COA  may  avoid  the  threat,  but  the  excess 
distances  incurred  will  cause  a  delay  in  L-Hour  at  the  current  cruise  speed  of  120 
kts  and  decrease  the  escort’s  time  on  station  by  20  minutes  due  to  fuel 
constraints.  (6)  Select  Best  Alternative  Plan:  The  pilot  or  mission  commander 
must  choose  to  ignore  the  proposed  COA  or  select  the  best  fit  for  the 
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circumstances.  (7)  Communicate  &  Implement  Chosen  Plan:  Once  the  pilot 
selects  the  candidate  COA  the  new  plan  intention  is  transmitted  to  the  JIG.  (8) 
Validate  &  Improve  the  Model:  The  model  is  then  updated  with  the  new  plan  and 
the  cycle  begins  anew. 
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III.  THE  I -AM  ARCHITECTURE 


A.  FRAMEWORK 

The  framework  of  the  l-AM  architecture  was  constructed  under  the 
following  assumptions: 

1 .  A  Joint  Operation  Area  Information  Grid  (JIG)  network  exists  and  it  is 
capable  of  efficiently  networking  all  battlefield  entities  in  real  to  near  real 
time. 

2.  Battle  space  entities  equipped  with  l-AM  are  in  essence  distributed 
systems  that  share  a  common,  synchronized  “world”  model. 

3.  A  communication  technology  &  protocol  exists  that  can  efficiently  route 
valuable,  relevant  information  to  the  user  that  requires  it,  and  quite  often 
before  he  knows  he  needs  it. 

4.  For  this  architecture,  the  pilot  is  considered  the  “planner.”5  Mission 
planning  utilizes  an  l-AM  planning  client  that  is  connected  to  JIG.  The 
completed  mission  plan  is  uploaded  to  the  JIG  and  distributed  in 
advance  to  all  Distributed  C2  entities  in  preparation  for  the  mission. 


B.  COMPONENTS 

1.  PHYSICAL  VIEW 

Figure  1  depicts  the  l-AM  aircraft  client’s  architecture’s  physical  view.  It  is 
redundant  in  nature  to  meet  pilot  and  copilot  desired  views  as  well  as  provide  an 
error  cross  check  capability  to  compensate  for  system  malfunctions  or  battlefield 
damage.  Additionally,  it  incorporates  a  Redundant  Array  of  Independent  Disks 
(RAID)  design  that  accommodates  a  large  data  storage  capacity.  Back  up 
storage  is  also  provided  by  a  separate  emergency  hard  drive.  The  l-Am  client  is 

5  It  is  conceivable  that  a  mission  could  be  planned  by  someone  other  than  the  assigned 
aircrew  and  “pushed”  down  through  the  JIG  for  execution. 
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furnished  power  through  redundant  generators  and  is  equipped  with  an  8  hour 
battery  back  up  capability.  Additionally,  a  robust  surge  suppression  and  power 
fault  capability  is  built  in.  Cooling  for  the  system  is  provided  by  redundant 
modular  cooling  units  located  in  the  avionics  bay.  The  JIG  World  Model  & 
associated  mission  filtered  model  can  be  downloaded  via  disk,  or  via  the  JIG. 
The  system  also  accepts  manual  pilot  inputs. 


Figure  1:  l-AM  Physical  View 
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SYSTEM  VIEW 


Figure  2:  l-AM  System  View 
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3.  QUALITY  ATTRIBUTES 

Several  quality  attributes  are  applicable  to  the  l-AM  client  system.  They 
include  synchronicity,  currency,  security,  flexibility,  redundancy,  timeliness, 
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accuracy,  and  conciseness.  This  list  is  certainly  not  all  inclusive.  The  three 
quality  attributes  addressed  in  this  paper’s  architectural  analysis  are  timeliness, 
accuracy,  and  conciseness.  Timeliness  of  the  architecture  refers  to  the  speed  of 
which  the  system  processes  received  information  in  order  to  provide  the  design 
response  (notify  pilots  visually,  generation  of  candidate  plans,  inform  JIG). 
Accuracy  pertains  to  the  ability  of  the  data,  calculation  output,  &  display  to  meet 
mission  required  tolerances.  Conciseness  refers  to  non-verbose  nature  of  how 
information  is  input,  displayed,  and  transmitted.  Information  flow  is  non  verbose 
in  nature  and  pushes  information  by  exception  only. 

4.  QUALITY  REQUIREMENTS 

The  system  is  designed  to  receive  external  information  from  the  JIG  and 
internal  information  from  onboard  sensors  &  navigational  equipment  to  (1) 
provide  the  pilot  with  a  visual  display  of  the  information  (cockpit  digital  map 
display,  alert  message  center,  counsel  information  display),  (2)  provide  the  pilot 
with  candidate  plans  and  options  to  counter  unexpected  threats  &  scenarios,  and 
(3)  transmit  aircraft  status  &  mission  updates  by  exception  to  the  JIG.  Figure  3 
depicts  the  priority  requirements  of  the  l-AM  helicopter  client. 

The  l-AM’s  critical  core  functional  requirements  that  enable  these  outputs 

are: 

1 .  Concurrent  candidate  plan  generation  &  updating. 

2.  Continuous  threat  &  hazard  avoidance  predictions  calculated  in  real 
time  from  external  &  internal  information. 
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3.  Ability  to  dynamically  filter  in  real  time  the  views,  processes, 

simulations,  and  predictions  of  the  world  model  to  address  the  current 
mission  “slice”,  or  micro-model. 


Figure  3:  l-AM  PRIORITY  REQUIREMENTS 
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IV.  ARCHITECTURE  EVALUATION 


A.  WHY  IT’S  GOOD 

The  l-AM  architecture  is  designed  in  essence  to  be  “holonic.”6  In  this  regard, 
it  reflects  the  overarching  architecture  of  the  JIG  and  can  be  utilized  as  a  product 
line  applicable  across  multiple  platforms  and  sensors.  Variations  in  the  design 
would  be  needed  to  accommodate  specific  platform  attributes.  Typical  variants 
would  have  to  accommodate  platform  velocity  and  timeliness  requirements 
directly  related  to  candidate  plan  calculations  &  generated  model  views.  For 
example,  the  l-AM  views  and  information  processing  requirements  of  a  high 
performance  jet  aircraft  vary  immensely  in  comparison  to  a  Light  Armor  Vehicle 
(LAV). 

Three  scenarios  were  used  to  “stimulate”  and  analyze  the  functionality  of 
the  architecture.  The  scenarios  used  were: 

(1)  Null:  Helicopter  strait  &  level,  proceeding  in  accordance  with 
the  mission  plan,  updating  normal  GPS/NAV  information. 

(2)  Abrupt,  unexpected  90  degree  turn 

(3)  Pop-Up  threat  information  received  that  was  not  part  of  mission 
plan 

The  architecture  responded  well  to  all  of  these  scenarios  and  met 
the  basic  requirements  of  pilot  notification,  candidate  plan  generation,  and 
JIG  publishing.  The  utility  tree  diagrams  for  these  scenarios  are  listed 
below. 

6  Hyper-Beings:  How  Intelligent  Organizations  Attain  Supremacy  through  Information 
Superiority,  Part  I,  pre-publication  DRAFT.  Dr.  Rick  Hayes-Roth,  Nov  2003,  pp  5-6. 
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NULL  SCENARIO  UTILITY  TREE 


Figure  4:  NULL  Utility  Tree 
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Null  Scenario.  Helicopter  normal  flight  updating  GPS  &  on 
board  nav  data 
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ABRUPT  90  DEGREE  TURN  SCENARIO  UTILITY  TREE 


Figure  5:  90  Degree  Turn  Utility  Tree 
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Scenario  #2:  Sudden  90  Degree  turn 
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POP-UP  THREAT  INFORMATION  RECEIVED  FROM  JIG 


Figure  6:  Pop  Up  Threat  Utility  Tree 
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Scenario  #3:  Pop-Up  Threat  Data  Received 
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B.  VULNERABILITIES 

The  scenarios  identified  three  notable  vulnerabilities  of  the  l-AM 
architecture. 

a.  Ability  to  discern  and  correct  from  corrupt  data  input. 

b.  Timeliness  of  threat  avoidance  candidate  plan  generation  &  the 
need  to  perhaps  perform  continuous  parallel  threat  &  hazard 
forecasts  (at  minimum  for  Divert,  egress,  resume  course, 
emergency  procedures).  This  would  be  necessary  to  mitigate 
latency  in  providing  the  pilot  with  time  critical  evasive  action  / 
hazard  avoidance  recommendations. 

c.  Timeliness  of  profile  view  generation 

C.  SENSITIVITIES 

The  following  sensitivities  were  discovered  as  a  result  of  the  scenarios: 

1 .  Latency  in  generating  the  filtered  model  view  directly  impacts  the 
ability  to  generate  the  filtered  JOA  world  model  current  &  forecast 
states,  and  candidate  plan  generation. 

2.  Latency  associated  with  the  filtered  view  generator  could  impact 
hazard  &  threat  avoidance  calculations,  recommended  actions,  & 
notification. 

3.  Update  module  could  conceivably  corrupt  the  world  models  with 
inaccurate  or  malicious  input  data  causing  invalid  states  and 
predictions. 


19 


D.  TRADE-OFF  POINTS 

The  filtered  model’s  perspective  and  accuracy  will  very  with  the  depth  of 
view  used  by  the  view  generator.  The  potentially  large  battle  space  reflected  in 
the  filtered  model  may  preclude  accurate,  timely  forecasts  and  candidate  plan 
generation.  This  could  be  off  set  by  creating  a  filtered  subset  where  slices  in  the 
near  term  are  held  to  more  stringent  predictive  calculations  than  slices  at  the 
distant  4-D  space  boundary.  Therefore,  prediction  probabilities  increase  with 
time  as  the  aircraft  nears  the  next  “slice”  and  more  detailed  level  data  is  received 
for  calculations.  Thus  the  system  is  not  bogged  down  with  attempting  to 
calculate  every  possible  contingency  for  a  large  swath  of  filtered  battle  space. 
Fig.  7  depicts  a  hypothetical  view  of  the  filtered  battle  space  with  respect  to  time 
for  model  calculations. 


Dynamic  Filtered  Model  View 


Figure  7:  Filtered  Battle  Space  vs.  Time 
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E.  RISK  MANAGEMENT  STRATEGY 

The  analysis  of  the  architecture  provided  insight  into  several  potential  risk 

mitigation  options. 

1.  Redundant  system  functionality  for  robustness: 

The  l-AM  client  should  be  designed  for  climate  extremes,  to  include 

sandy  &  dusty  conditions.  The  system  is  composed  of  dual  CPUs,  RAID, 
backup  storage,  and  is  equipped  with  battery  back  up  &  power  surge 
capability. 

2.  Visual  system  status  indication  redundancy: 

The  architecture  should  utilize  redundant  visual  options  to  validate 

system  status  to  the  pilot.  This  can  be  done  through  use  of  subtly  flashing 
icons  on  the  digital  map,  backed  up  by  a  pulsing  light  on  the  alert  message 
center,  and  further  announced  via  a  short  text  message  “ok”,  for  example. 

3.  Parallel  hazard  forecast  &  candidate  plan  generation 

The  architecture  should  calculate  candidate  options  (egress,  divert,  EP, 

etc)  in  parallel  with  the  current  to  forecast  state  model  generation  vice  performing 
the  calculation  when  a  hazard  or  threat  condition  is  detected.  This  will  improve 
response  timeliness  in  scenarios  where  threat  avoidance  or  mitigation  is  time 
critical. 

4.  Threat  Modeling  &  Prediction 

Candidate  plans  for  hazard  &  threat  avoidance  should  be  continuously 
updated  &  modeled  to  increase  timely  &  accurate  predictive  models  of  enemy 
actions  based  on  the  aircraft’s  projected  4-D  mission  slice 
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5.  Wide  filtered  model  view 

The  filtered  system  view  should  strike  a  balance  between  being  large 
enough  to  foresee  &  calculate  future  threat  actions  without  sampling  so  large  of  a 
battle  space  that  it  incurs  an  unacceptable  latency  in  pilot  notification  &  threat 
avoidance  actions.  (See  figure  7) 

6.  Input  message  format  filtering 

The  architecture  should  implement  an  input  filter  that  is  capable  of 
restricting  input  data  to  the  proper  format  in  order  to  mitigate  the  potential 
corruption  of  model  data. 

7.  Need  for  alert  notification  precedence 

There  exists  a  potential  to  overwhelm  aircrew  with  numerous  hazard  & 
threat  alerts.  The  architecture  requires  a  threat  and  hazard  precedence 
classification  be  created  to  prioritize  &  filter  these  alerts.  Potential  notification 
classes  are:  Flash  (potential  for  loss  of  life),  immediate  (impacts  mission  goals  or 
Cdr’s  intent),  priority,  routine,  etc. 

8.  Data  input  error  cross  checking 

The  system  should  have  the  ability  to  cross  check  primary  GPS  heading  & 
track  data  with  secondary  navigational  instrument  data  fir  1st  order  determination 
of  data  accuracy  &  to  ensure  proper  format  (i.e.  filter  for  corrupt  data). 
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APPENDIX  A:  SCENARIO  BASED  ARCHITECTURE  FLOWS 


A.  NULL  SCENARIO  ARCHITECTURE  FLOW: 


Carlo  m  IS  ilS2  HID  Aware  Modi  t :  He  icoptE r 
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B.  90  0  SCENARIO  ARCHITECTURE  FLOW: 


CanoiDi  IS  i  1 02  1 1  tti  fim  are  ieix  Hodik:  Helfcopter 


24 


C.  POP-UP  THREAT  SCENARIO  ARCHITECTURE  FLOW: 


Carlo  m  10  i132  lit  Aw  are  i  eu  Modi  fe:  He  llcopter 
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Intent  of  Paper... 

+  Illustrate  a  thread,  or  mission  slice  of  a  Network  Centric 

construct  via  the  lens  of  a  tactical  helicopter  pilot  [see  operational 

vignette  in  paper  or  background  slides] 

+  Propose  a  Model-based  Communication  Network  (MCN) 
software  architecture  solution  for  distributed  battlefield 
information  awareness  and  C2 

(1)  Provides  the  networked  warrior  a  higher  probability 
of  mission  success  and  survivability 

4  (2)  Elucidates  an  achievable  goal  that  can  evolve  into  a 
battlefield  wide  NCW  componency 

*  (3)  Illustrates  that  adherence  to  interoperability 
standards  alone  is  insufficient  to  transform  today’s 
warfighter  into  the  network  centric  force  of  tomorrow 


The  Situation... 


The  network  is  no  longer  confined  to  the  garrison  network 
operation  centers  (NOCs)  or  command  post  headquarters 

+■  Information  is  now  permeating  our  tactical  combat  systems 
(aircraft,  vehicles,  ships,  ordnance)  and  personnel  (rugged 
PDAs,  etc.) 

#  Most  all  tactical  fighter  aircraft  today  are  “Fly-by-Wire” 

#  Precision  Guided  Munitions 

+  Witnessing  the  co-evolution  of  molecules  and  information 
(Bits) 

Realization  that  it  is  the  software  that  enables  our 
combat  systems  to  achieve  capabilities  that  far  exceed  the 
mere  summation  of  their  molecules 


The  Realitv  of  Todav’s  Battlefield: 


e  Community  of  systems  (sensors,  platforms) 
and  actors  (Joint  &  Coalition)  equipped  with 
primarily  stove  piped  systems 


4*  Coupled  mainly  by  voice  &  a  limited  data 
networks 


♦  Lack  of  distributed  situational  awareness 


Commonality  of  interoperability  standards 
(COTS/GOTS)  and  middleware  alone  will  not 
produce  a  Net-Centric  Force 


— 


f 


A  Typical  Combat  Operation  Center  Senior 
Watch  Officer  Mantra: 

O  What  Do  I  know? 

O  What  Do  I  Need  to  Know? 

□  Who  Needs  to  Know  it? 

O  Have  I  Told  Them? 

Can  we  architect  this  concept  into  our  tactical  systems? 
Implication: 

■  Bits  have  value 

■  Information  should  be  Valuable,  elevan  ,  and 

Timely 


NCW  Architecture  Solution... 


+■  Propose  a  Model-based  Communication  Network  (MCN) 
architecture  that  addresses  the  innate  need  for  shared 

battlespace  awareness  in  near  real  time  [see  Dr.  Rick  Hayes-Roth  ICCRTS  paper 

#375] 

♦  Not  limited  to  aviation  assets 

♦  Intent  is  to  adopt  an  architecture  framework  that  supports  a 
software  product  line  approach  capable  of  addressing  this 
fundamental  warfighting  need  of  all  battlefield  entities  (Air,  Ground, 
Sea,  Space)  and  actors 

■f-  Shared  awareness  is  facilitated  by  the  tailored  exchange  of 
information  that  should  be  inherently: 

♦  Valuable 

♦  Relevant 

♦Timely 
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What  is  a  Model-based  Communication 

Network  ? 


Boyd's  OODA  Loop  (Decision  Cycle)  for  a  1v1 
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Has  a  Brain-Based  World  Model  at  it’s  Core 


Vo 


Today’s  Battlefield: 
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ps 

Current  Helicopter  System  Status  ...ffte  as  is: 

+  No  data  link 
+  No  moving  map 
+  No  Common  Operational  Picture 
+  Limited  GPS  navigation  system 

*  Limited/no  computer  integration  of  onboard  avionics/sensors 
with  internal  flight  and  external  C2  systems 

+  GPS  waypoints  can  be  downloaded  from  Portable  Flight 
Planning  System  (PFPS)  Software 

+  Voice  communication  and  IFF  provide  the  only  means  of 
dynamic  information  exchange  with  tactical  peers  and  JOA 
battlefield  entities 

4  Not  capable  of  receiving  or  sharing  external  sensor  threat 
information 


Helicopter  l-AM  Priority  Requirements 


A  Software  Architecture  Alternative: 

The  World  Model  &  Eight  Key  Functions  of  Efficient  Thought 

©-  Dr.  Rick  Hayes-Roth 
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Core  Functional  Requirement  Enablers 


Concurrent  candidate  plan  generation  &  updating 

Continuous  threat  &  hazard  avoidance  predictions 
calculated/correlated  in  real  time  from  external  & 
internal  information 

Ability  to  dynamically  filter  in  real  time  the  views, 
processes,  simulations,  and  predictions  of  the 
world  model  to  address  the  current,  relevant 
mission  “slice”,  or  micro-model 


The  Eight  Steps  Manifested  in  the  1-AM  Architecture 


1  .Observe: 

-  I-AM  observes  the  environment  by  monitoring  data  received 

Internally 

-Indigenous  onboard  sensors  (GPS,  RADAR  Warning,  IR  Warning, 
avionics  components  (temp,  barometric/RADAR  altimeters,  airspeed, 
attitude) 


Externally 

-  Satellite,  Command  &  control  aircraft,  intra  flight  communications, 
ground  based  stations 


2.  Assess: 

-  Compares  information  with  the  forecast  plan  model 

3.  Determine  Desired  Changes: 

-  I-AM  determines  the  degree  of  changes  to  make  to  the  model 


The  Eight  Steps  Manifested  in  the  I-AM  Architecture 


4.  Generate  Candidate  Plans: 

-  Candidate  COAs  are  generated  and  presented  to  the  pilot  for  acceptance 
•  i.e.  alternate  routes  to  circumvent  threats 

5.  Project  Likely  Outcomes: 

-  Ramifications  of  selecting  a  COA  are  modeled  and  analyzed 

6.  Select  best  Alternative  Plan: 

-  Pilot/Mission  Cdr  must  choose  to  ignore  the  proposed  COA  or  select  best  fit 
for  circumstances 

7.  Communicate  and  Implement  Chosen  Plan: 

-  Plan  intention  is  transmitted  to  the  JIG  upon  pilot  acceptance 

8.  Validate  &  Improve  the  Model: 

-  Model  is  updated  with  the  new  plan  and  the  cycle  begins  anew 


What’s  Under  the  Hood? 


rJOA  World  Model:  Present 

I  I 

JOA  World  Model:  Future**- 


Fnandly 


Enemy 


Stii]abl&  Storage 


Data 


Y*;. 

"jffidress  M$r 


No 


Data  InLul  Mgr 


If  K 
In  dmli 


J0C  Comm  Equp  ^ 

J^nf.  VHF,  HF. 

rflATCGM,  (ElMfiARS 
HAVtttJICK) 

ATO  FH  Kys  Monitor 

Air  Speed,  Akfcude, 
needmg.  Fuel  oty. 
Ordnance  lead,  .. 

tfl 

vc  Na^igwoo  MOnra* 

E 

GPSl  Hdg.  All.  irauh,  A' 
i3.  position.  pr^ecrflrt 
pasrian.  ..  |INfi, 

TACAN,  VDR,  AEF 

Pilot  Manual  ininiit 

1 

CO 

lu 

€ 

A'C  ^fireai  Sws  Idanibcii 

RADAR  ^arnng.iTfack 

IR  rtatoclian 

MAnuul  input 

£. 

£ 

AiV:  Sensor  Mannor 

— 

FUR. 

video 

RADAR 

< 

fv\  rx c  i  ut-  M  II  lliJI 

Tamp  Sarah  Pras 
winds  (GPS),  FTecip, 
Icing,  Cute. 

HW 

lation 


If  New 


info 


Model  update| 

Updates  ' 
World  Mod 

1 

Produc  ;s  


"EJpditi^ 


Arspace 

Conlrd 

Order 

Air 

Tasking 

txdsr 

Spa  dal 
infltTLKfltoiw 

Frirrklly 

QnJerdf 

BetJe 

Ena  my 
Order  uf 
Raise 

Master 

Air 

At^cK 

Plan 

Joint 

Ini  eg  rated 

PrUxIUzed 
Target  Lisl 

fin  min 

Damage 

Assssment 

Fry 

Sup  pan 

CosfiJiiati 

an 

Measures- 

Rstl 
Team 
Era  my 
Fc-rncasl 

METOO 

Rdule 

Flanndg 

Cdr'e  Intent 

opord; 
ofl  m 

Leglsll  me 

-  i 


Profile  View 

Generabar 

Jllnfs  World  model 
bAed  upon  airuaril^, 

Jg.  W9,  pes.  Ir-aic-H 
ih,  &  missim 


Provides 


T 

Tiranaarilon 

Mon  11  or 

Pdaimain  an 
update  leg  & 
slorc  inld  on  HD 

p^T] 

|  Emergency  Divert  COAs 

Candidate 

Plans^OpUons 

Filtered  World  Model 


Cenvsrl  Flan  Vj-  Curenl 
Updste  Ournerc  Mode! 
flalniJarte  Frajarhart  Martel 

r 


-  Has  tumrr.  or  projected 

mrkirls  produned  a  |lh.  wx, 
ihrral,  rculc,  frrfridrte,  elc.j 

hreard  state? 


rtaz-ard 

A^GHano# 

Cailculafar 


No 


ra  mere  I  hen  <;3| 

UUAsle  mitigate 

Ihraar 


Passive  Alert 


Hj-Jivr:'  Wen  |:ilnf  w.'  aurtbin 
Inne,  Caulion  &  Advisory  liijil 
based  on  data  eten  pmadGras 
2  Passive1  FlwJnmg  tl\ap 
Replay  alen  and  kKjra.  aute 
ipirtalraof  pos.  A/5,  air. 


Pilot  Ig  lores  CO  As 


Active  Alert 


Map  Uixiale  Mgr 

Refr&filv'Re-plot 
cu  rr&nt  profile  ;Ja on 
moving  map, 'Digital 
Display 


Pilot  d&lE 
COA 


Onboard  Systems 

Furnish  aircraft  AiS.  All,  Pot,  Track,  Hdg  to 
PfOllle  Yi&w  Qsn&rator 


GRID  Update  Module 

Publish  MSN 
profile  updates  & 
Grid  RFIs  (Rqsts 
for  Info). 


The  Helicopter  s  Filtered  World  Model 


horecast  state 


Current  Staten 


Egress 

Emergency  Divert  COAs 

Candidate 

Plans/Options 

Take  away... 


*  NCW  means  changing  the  way  systems  behave  to  support 
the  personalized  requirements  of  the  warfighter 

Bits  have  contextual,  perishable  value 

*  We  cannot  get  there  without  a  common,  shared,  software 
architecture  model 

#•  Though  this  slice  can  be  generalized  to  other  operators,  it 
will  simply  not  emerge  from  a  generic  approach  to  Enterprise 
Architecture  (EA)  or  a  standardization  of  communication 
“pipes” 
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The  Operational  Vignette  Behind  the  I- AM  Architecture: 

The  Joint  Force  Air  Component  Commander’s  (JFACC)  Air  Tasking  Order 
(ATO)  for  the  following  day’s  air  operations  was  released  at  1800z.  On  board  the 
amphibious  assault  ship  Tarawa,  pilots  of  Marine  Heavy  Helicopter  Squadron  (HMH)  465 
(Reinforced)  continued  their  mission  planning  for  the  following  day’s  assault.  HMH-465 
was  a  composite  squadron  and  was  designated  as  the  Aviation  Combat  Element  (ACE) 
for  the  15th  Marine  Expeditionary  Unit  (MEU).  The  squadron  was  comprised  of  a  mix  of 
CH-53X,  AH-1Y,  UH-1Z,  MV -22,  and  Joint  Strike  Fighter  (JSF)  aircraft.  Utilizing 
Information  Awareness  Module  (I -AM)  mission  planning  client  terminals  in  the  Ready 
Room,  pilots  were  able  to  access  a  mission  planning  application  that  dynamically  fused 
and  interacted  with  the  Joint  Operation  Area  Information  Grid  (JIG).  Upon  entering  the 
ATO  assigned  mission  ID,  their  “slice”  of  the  battle  space  was  filtered  and  made  available 
for  planning.  Routing  options  were  displayed  based  upon  the  constraints  &  framework  of 
the  Air  Tasking  Order  (ATO),  the  Air  Space  Control  Order  (ACO)  &  Special  Instructions 
(SPINs).  Threat  observations,  assessments,  and  expectations  fed  from  the  Enemy 
Air/Ground  Order  of  Battle  information  were  fused  with  the  Commander’s  Intent  (strategic 
through  tactical),  the  Friendly  Air/Ground/Sea  Orders  of  Battle  and  Meteorological 
(METOC)  information  that  generated  optimum  mission  paths  for  aircrew  selection.  The 
pilots  then  entered  the  detailed  mission  specifics  (number  of  aircraft,  specific  take 
off/landing  times,  fuel  &  ordnance  loads,  LZs,  targets,  objectives,  etc.)  and  system 
calculated  go-no-go  criteria,  optimum  airspeeds,  ordnance,  fuels  loads,  divert  options,  and 
printable  knee  board  mission  “smart  packs.  ”  The  mission  commander  approved  the  plan, 
and  it  was  simultaneously  uploaded  into  the  JIG  and  down  linked  (or  manually  disk 
loaded)  into  each  of  the  squadron’s  aircraft  in  preparation  for  the  following  day’s  mission. 


The  aircrew  manned  up  their  aircraft  at  0600.  As  the  on  board  flight  computers  came 
on  line,  each  aircraft’s  l-AM  logged  into  the  JIG.  Immediately,  updates  from  the  last  24  hours 
of  battle  were  received  and  the  preplanned  mission  was  dynamically  updated  &  transformed 
into  a  current  model  for  execution.  As  the  aircraft  lifted  off  and  proceeded  feet  dry,  on  board 
sensors  (GPS,  Radar  Warning  Receivers),  Navigational  Instruments  (airspeed,  barometric 
altimeter,  fuel  flow/quantity,  etc.),  and  the  IFF  command  &  control  module  (Identification  Friend 
or  Foe  C2)  began  to  publish  the  current  state  of  each  aircraft  as  they  pressed  on  along  their 
mission  ingress  routes.  Intra-flight  and  inter-JIG  communication  was  minimized  by  adhering  to 
the  rule  of  publishing  information  by  exception.  That  is,  there  was  no  requirement  for  mission 
status  updates  as  long  as  the  flight  proceeded  within  the  plan  tolerance  “known”  by  all  need  to 
know  JIG  C2  entities.  Occasional  aircraft  “heartbeats”  published  the  aircraft  state  to  the  JIG  in 
order  to  facilitate  C2  and  avert  fratricide.  These  status  heart  beats  were  programmed  to  occur 
on  a  seemingly  random,  yet  algorithmically  controlled  basis  to  counter  enemy  tracking  & 
spoofing. 

As  the  flight  approached  phase  line  red,  the  aircrew  completed  their  penetration 
checklists.  Door  gunners  test  fired  their  weapons,  and  the  aircraft  assumed  a  terrain  flight 
(TERF)  profile  at  50  feet  to  avoid  enemy  radar  detection.  Satellite  ELINT  sensors  orbiting  high 
over  the  joint  operating  area  detected  new  enemy  early  warning  &  target  tracking  radars 
associated  with  a  surface  to  air  missile  launcher  in  close  proximity  to  the  route’s  Initial  Point 
(IP).  Once  detected,  the  information  was  published  to  the  JIG  where  it  was  then  routed  to  all 
entities  that  were  either  determined  to  be  in  critical  need  or  were  valid  subscribers  of  this 
particular  subset  of  information.  Immediately,  the  cockpit  information  display  alerted  the  pilots 
of  critical  new  information  that  directly  impacted  the  planned  mission.  The  aircrew’s  attention 
was  immediately  drawn  to  the  digital  map  display  where  the  new  threat  was  accurately  plotted 
complete  with  threat  rings.  The  copilot  immediately  selected  the  hazard  avoidance  overlay 
button  and  three  optimum  routes  to  the  LZ  were  displayed  over  the  existing  profile. 


Since  L-Hour  was  firm,  the  Air  Mission  Commander  selected  the  option  that 
ensured  the  mission  would  meet  its  time  on  target  (TOT)  in  addition  to 
maximizing  the  fuel  available  for  the  AH-1Y  escorts.  Instantaneously,  the  JIG 
&  all  aircraft  in  the  flight  were  updated  with  the  new  plan  information.  As  the 
flight  maneuvered  along  their  new  route,  the  Joint  Strike  Fighters  escorts 
quickly  neutralized  the  pop  up  threat.  The  rest  of  the  mission  proved  to  be 
uneventful.... 
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Figure  2.  Efficient  thought  employs  eight  key  fuuctions  supported  by  a  work! 

model. 

The  eight  steps  are  numbered  in  a  typical  sequence,  though  in  most  complex 
organizations  all  eight  steps  operate  in  parallel.  The  intelligent  being  (1)  observes 
what 3  s  happening  in  the  environment,  (2)  assesses  the  situation  for  significant 
threats  and  opportunities,  (3)  determines  what  changes  would  be  desirable,  (4) 
generates  candidate  plans  for  making  those  changes,  (5)  projects  the  likely 
outcomes  of  those  plans,  (6)  selects  the  best  plan,  and  (7)  communicates  that  plans 
to  key  parties  and  implements  it.  Throughout,  the  intelligent  being  (8)  validates 
and  improves  its  model.  The  model  supports  all  eight  activities,  although  only 
steps  1.  2.  7  and  8  directly  update  and  modify  the  model. 


